a. それがなぜ大変なの？

既存のバックログは、 LeSS のプロダクトバックログとして使えないから

古い「アイテム」のほとんどは、単一機能をもつチーム（分析、設計、テストなど）が前提の機能タスクと、コンポーネントチームが前提のコンポーネントタスクであることが多い

古い組織の前提にもとづいているタスクは、 LeSS の新しいフィーチャーチームの組織構造では意味をなさない

新しい形のアイテムを理解していないから

アイテムは真に顧客中心でエンド・ツー・エンドで表現され、理解されている必要がある

以前はサイロ型チームだったせいで、新しくなったアイテムでは新しく生まれっるフィーチャーチームにとって必要な学習がたくさんある

限られた顧客中心視点の知識になっているから

以前のアイテムが顧客中心の表現になっていたとしても、サイロ型の専門家は狭いタスクに注目するため、完全な顧客中心の視点を理解していない

新しい形のアイテムの見積もりが（ない or 不十分 or 不適当）だから

新しくなったアイテムには見積もりが必要。アイテムが作り直されていなくても、以前のチームが見積もっていればやり直しが必要になることがある

プロダクトオーナーは長い期間の計画をするために、ほとんどまたは全部のアイテムの見積もりが必要な場合もある

新しく広がったプロダクトの定義が十分に理解されていないから

既存のバックログのいくつかは新しく広がったスコープに合わせる必要があるかもしれない

新しいプロダクトビジョンを作り広めること

たくさんの知識のギャップがあること

互いに馴染みのない人と一緒に仕事をすること

プロダクトビジョンが共有されていないから

従来のサイロ型のグループでは、プロダクトビジョンを知っている人はほとんどいない

最初の PBR は共通のビジョンを形作り、話し合い、調整を始める機会である